Ready

Summary

• Refactors all Kiali MCP tools to delegate execution to Kiali's backend /api/chat/mcp/* endpoints instead of implementing the logic locally
• Removes ~3,000 lines of duplicated Go code that replicated Kiali-internal logic (health calculation, graph assembly, trace formatting, log retrieval, Istio config management)
• Adds comprehensive test coverage for the Kiali HTTP client and config validation

Motivation

Kiali's UI already ships a built-in chatbot that uses the same MCP tool semantics. Maintaining two independent implementations of the same tools — one in the Kiali backend and one here in the MCP server — created several problems:

1. Duplicated logic: Health calculation, graph assembly, trace summarization, and Istio config management were reimplemented in this repository, diverging from Kiali's canonical behavior over time.
2. Version skew: Output formats and default parameters drifted between the Kiali UI chatbot and the MCP server, producing inconsistent experiences.
3. Large tool schemas and responses: Each tool carried verbose input schemas and produced large JSON responses because the MCP server had to expose every upstream parameter and return raw API data.
4. Limited CI coverage: Complex Kiali-specific logic (e.g., health status rollup across namespaces) was hard to integration-test without a live Kiali instance.

What changed

Architecture

Before: each tool handler built REST API calls to multiple Kiali endpoints, parsed JSON responses, computed derived data (health rollups, graph merges), and formatted output.

After: each tool handler is a thin wrapper that POSTs to <kiali-url>/api/chat/mcp/<tool_name> with the tool arguments as JSON. Kiali's backend owns all data fetching, aggregation, and LLM-optimized formatting.

Deleted (~3,000 lines)

• pkg/kiali/: 15 files removed — health_calculation.go (626 lines), get_mesh_graph.go, graph.go, traces.go, logs.go, services.go, workloads.go, istio.go, mesh.go, namespaces.go, validations.go, types.go, endpoints.go, etc.
• pkg/toolsets/kiali/: 7 files removed — get_mesh_graph.go, get_metrics.go, get_resource_details.go, get_traces.go, helpers.go, helpers_test.go, logs.go, manage_istio_config.go

Added

• pkg/toolsets/kiali/tools/: 9 thin tool handlers (~60–90 lines each) that define the tool schema and delegate to kiali.ExecuteRequest()
• pkg/toolsets/kiali/tools/endpoints.go: centralized MCP endpoint path constants
• pkg/toolsets/kiali/internal/defaults/: shared default values for tool parameters
• pkg/kiali/tests/: endpoint coverage test ensuring every endpoint constant is wired to a tool implementation, plus backend contract test scaffolding

Improved test coverage

• kiali_test.go: no-config initialization, empty endpoint, non-2xx error handling (with/without body), JSON body serialization, header assertions (Content-Type, X-Kubernetes-MCP-Server, POST method), Bearer token edge cases (empty, already-prefixed)
• config_test.go: direct Validate() tests for nil config, empty URL, invalid URL, URL without scheme, HTTP vs HTTPS certificate requirements
• pkg/mcp/kiali_test.go: rewritten to test the new architecture (single POST per tool, MCP endpoint paths, JSON argument forwarding)

Benefits

• Smaller tool schemas — input schemas only expose what the LLM needs; Kiali handles defaults and validation server-side
• Smaller responses — Kiali returns pre-formatted, LLM-optimized text instead of raw JSON that the MCP server had to post-process
• Single source of truth — tool behavior is controlled by the Kiali release, eliminating version skew with the Kiali UI chatbot
• Better testability — Kiali tests all tool logic in its own CI with full integration tests against a live mesh
• Simpler maintenance — adding or modifying a tool requires changes only in the Kiali backend; the MCP server just needs a thin handler and endpoint constant

Test plan

• make test passes (all 25 packages green)
• Endpoint coverage test verifies every endpoint constant is used by a tool
• Kiali HTTP client fully tested (auth, headers, error codes, body serialization, response limits)
• Config validation fully tested (nil, empty, invalid URL, HTTP/HTTPS cert logic)
• MCP integration tests verify tool registration, correct endpoint routing, and response forwarding

Summary evals

=== Evaluation Summary ===

✓ Create Istio Gateway (assertions: 3/3)
✓ Remove Fault Injection (assertions: 3/3)
✓ List and Validate VirtualServices (assertions: 3/3)
✓ List and Validate DestinationRules (assertions: 3/3)
✓ Update Traffic Shifting (assertions: 3/3)
✓ Analyze Service Traffic Volume (assertions: 3/3)
✓ Analyze Workload Response Times (assertions: 3/3)
✓ Identify Degraded Namespaces (assertions: 3/3)
✓ List Mesh-Enabled Namespaces (assertions: 3/3)
✓ Inspect Service Details (assertions: 3/3)
✓ Inspect Workload Details (assertions: 3/3)
✓ Inventory Namespace Services (assertions: 3/3)
✓ Inventory Workloads with Sidecar Status (assertions: 3/3)
✓ Comprehensive Mesh Health Audit (assertions: 3/3)
✓ Visualize Namespace Traffic (assertions: 3/3)
✓ Audit Control Plane Connectivity (assertions: 3/3)
✓ Visualize Cross-Namespace Traffic (assertions: 3/3)
✓ Visualize Workload-Level Topology (assertions: 3/3)
✓ Debug Service Errors via Logs (assertions: 3/3)
✓ Analyze Latency with Distributed Tracing (assertions: 3/3)
✓ Retrieve Recent Workload Logs (assertions: 3/3)

Tasks: 21/21 passed (100.00%)
Assertions: 63/63 passed (100.00%)
Tokens: ~82147 (incomplete - some counts failed)
MCP schemas: ~59787 (included in token total)
Judge used tokens:
Input: 98980 tokens
Output: 3199 tokens